What

transactions becomes server-write-only: authenticated loses its INSERT grant, and the two API routes that used it (/api/payments/checkout, /api/stripe/create-payment-intent) write on the admin client instead. A student can no longer open a pending row that under-quotes what it owes.

Closes #538

Why

#528 closed self-declared payment by pinning status = 'pending' on the user-scoped INSERT policy. It deliberately said nothing about what a legitimately pending row claims it is owed — and the Solana settlement columns are exactly that. Both Solana paths verify against the row's own figures:

• lib/payments/solana-reconcile.ts:104 → verifySplitTransfer({ totalBase: settlement_base }), reached from /api/payments/solana/verify and the /api/cron/solana-reconcile backstop
• app/api/payments/solana/tx/route.ts:119 → the payment request the wallet is handed

So a student could POST /rest/v1/transactions directly with a pending solana row for a $49 product carrying settlement_currency: 'sol', settlement_base: 1, pay one lamport, and have the verify endpoint confirm the transfer and flip the row to successful on the service-role client — firing trigger_manage_transactions and granting the entitlement. Full course access for a fraction of a cent, through the legitimate payment path. Reproduced against a local database:

 transaction_id | amount | settlement_currency | settlement_base
----------------+--------+---------------------+-----------------
          10004 | 100.00 | sol                 |               1

The same row shape also under-quotes amount. That does not buy access for Lemon Squeezy / PayPal / Binance — those charge from their own catalogue, and lib/payments/webhook-dispatch.ts never reads amount — but getPayoutsOwed() sums it, so an under-quoted row understates what the platform owes the school.

Which columns are load-bearing (the issue asks this before choosing a control):

The root cause is the grant, not the columns. Nothing in the browser inserts into transactions; every legitimate insert is already server-side, and the two API routes are the only reason authenticated held the grant. Both already derive amount, currency and payment_provider from tenant-scoped products / plans reads, and the settlement figures from getSolUsdPrice(). So:

1. Both inserts move to the admin client — the pattern transactions RLS restricts rows but not columns — a student can self-insert a 'successful' sale #528 applied to enrollUser. user_id comes from the verified session and tenant_id from the x-tenant-id header, so the tenant validation CLAUDE.md requires is already in place.
2. REVOKE INSERT ON public.transactions FROM authenticated, anon — POST /rest/v1/transactions now fails with permission denied for table transactions. Combined with transactions RLS restricts rows but not columns — a student can self-insert a 'successful' sale #528's UPDATE column grant, amount and all four settlement columns are unreachable by an untrusted caller on both verbs.
3. transactions RLS restricts rows but not columns — a student can self-insert a 'successful' sale #528's INSERT policy is kept and tightened to pin the four settlement columns NULL. It is unreachable while the grant is revoked; it is there so this specific under-quote stays impossible if the grant ever returns (a rollback, a schema dump re-applying the original GRANT ALL, or someone resolving a permission denied error the direct way).

Two directions from the issue were considered and rejected:

• A BEFORE INSERT trigger recomputing the values (the Split snapshot is written at a single call site with no DB backstop (#496 follow-up) #512 pattern) would overwrite legitimate ones — completing a payment request inserts the admin-confirmed payment_amount, and grant_free_subscription() inserts a zero-amount row for its plan. It also cannot help with native SOL, whose settlement_base comes from a live quote a trigger cannot obtain.
• A SECURITY DEFINER RPC has the same blind spot from the other side: it would have to accept the SOL/USD rate as a caller parameter, and that rate is precisely the value that must not be caller-supplied since settlement_base is derived from it. It moves the vulnerability rather than closing it. The admin-client insert keeps the quote from crossing the client boundary in either direction.

How to QA

On a fresh npm run db:reset (the migration is included in the chain), with npm run dev running:

1. The vulnerability is closed. Run the verify snippet — every row should report PASS, including a live attempt at the exact insert from the issue:

   docker exec -i supabase_db_lms-front psql -U postgres -d postgres \
     -f - < supabase/snippets/verify_transactions_insert_lockdown.sql

2. The regression spec. Covers both halves — a signed-in student cannot insert (under-quoted or honest), and /api/payments/checkout still creates the pending row priced from the product:

   npx playwright test transaction-insert-lockdown --workers=1

   To confirm these are real regression tests, apply supabase/migrations/rollback/20260725180000_transactions_insert_lockdown.down.sql and re-run -g "INSERT is closed" — both negative tests fail. Re-apply the migration afterwards (or npm run db:reset).
3. The legitimate Solana path by hand, if Solana is configured for the school: buy a solana product as alice@student.com on code-academy.lvh.me:3005 and confirm the pending row still lands with the correct settlement_base / settlement_currency / settlement_mint, written by the admin client.
4. The free-plan path (the one place a SECURITY DEFINER function inserts as a user): claim a free plan and confirm the zero-amount successful row is still created. Its DEFINER owner holds the INSERT privilege, so the revoke does not reach it.

Screenshots / GIF

Not applicable — no user-visible change. This is a database grant plus two server-side client swaps; the checkout UI is byte-identical.

Checklist

• npm run typecheck and npm run test:unit pass (370 unit tests)
• npm run build passes
• Every new tenant-scoped query filters by tenant_id (or the table genuinely has no such column)
• Tested with every relevant role (student / teacher / admin) — student is the only role with a path to this table; the admin-side manual-payment insert already used the admin client and is unchanged
• Loading and error states handled — the routes' existing Failed to create transaction branch covers the insert
• New UI strings added to both messages/en.json and messages/es.json — n/a, no UI strings
• Migration applies cleanly on npm run db:reset, has RLS policies, and lib/database.types.ts was regenerated — no regeneration needed, the migration adds no columns or types

Test results

• npx playwright test transaction-insert-lockdown --workers=1 — 16/16 pass across all four projects
• parallel-subscription-guard, payment-flows, enrollment-flows, entitlements-overlap, tenant-isolation — all pass on a fresh db:reset
• Two failures showed up while testing and are pre-existing on master — verified by stashing this branch's changes, resetting the database, and re-running: auth-security.spec.ts:23 (sign-up form fields) and subscription-lapse.spec.ts:113 (perpetual product entitlement from seed data). Neither touches transaction grants. subscription-lapse also leaves alice without her seeded subscription, which is what makes parallel-subscription-guard fail if it runs afterwards in the same session.
• npx eslint on the changed files — 0 errors, 1 pre-existing warning (itemName unused, create-payment-intent/route.ts:125, untouched by this PR)

Notes for the reviewer

• The migration is local-only. It has not been applied to the cloud project, same as transactions RLS restricts rows but not columns — a student can self-insert a 'successful' sale #528's.
• create_transaction_for_renewal(sub_id, usr_id, pln_id) (20260126190500_lms_complete.sql:402) is SECURITY INVOKER, granted to anon/authenticated, and inserts into transactions. It was already unreachable for a user caller — it sets no tenant_id, so transactions RLS restricts rows but not columns — a student can self-insert a 'successful' sale #528's policy rejected it — and no application code calls it. After this migration it fails one step earlier, at the grant. Flagged rather than changed; it looks like dead code worth removing separately.
• handle_new_subscription's EXECUTE grant to authenticated (20260704190000) was justified by enrollUser inserting as the user. That has been the admin client since transactions RLS restricts rows but not columns — a student can self-insert a 'successful' sale #528, so its comment is now stale, but nothing here depends on the grant either way.